Service Component Architecture (SCA) is a programming model for building applications and solutions based on a Service Oriented Architecture. SCA describes the content and linkage of an application in assemblies called composites. FIG. 1 is a diagram illustrating an example of SCA composite. SCA composites contain internal elements such as components 102, services 104, references 106, 108, shown in FIG. 1. SCA elements can have policies attached to them so that they exhibit desired non-functional properties, such as security and transactional properties. There are two kinds of SCA policies: policy intents and policySets. The policy intents are defined as keywords to describe the abstract policy requirements of SCA elements and/or requirements of interactions between components represented by services and references. Using intents, developers and assemblers can state these policy requirements in a high-level abstract form without the detailed configuration of the runtime and bindings. PolicySets can contain policies expressed in concrete form, such as WS-Policy assertions.
FIG. 2 is an XML representation for SCA composite. The SCA policy intents and policySets can be specified as “requires” attributes 202, 204 of SCA elements. Some domain-specific intents are defined in SCA policy specification as follows:
Security policy intents:                authentication        integrity        confidentiality        
Transaction policy intents:                managedTransaction        noManagedTransaction        propagatesTransaction        suspendsTransaction        transactedOneWay        
In SCA policy specification, valid sets of intents are defined. For example, all security intents can be applied to a same element. As for transaction, “propagatesTransaction” and “noManagedTransaction” are defined as “incompatible intents”. Also policy intents, which are applied to a component are inherited to the lower-level composite in case a component includes another composite. Users have to apply policy intents and policySets considering such restrictions and qualifications.
Open SOA proposed SCA policy representation as part of the SCA policy framework. Some domain-specific SCA policies are discussed, such as SCA security policy and SCA transaction policy. SCA policy framework defines security intents and policySets, and how to attach intents and policySets to a SCA composite. The SCA policy attachment mechanism is quite flexible, such that one can attach intents and policySets, e.g., specify abstract policies using intents such as “authentication” or “integrity” to any kinds of elements in a composite. However, there are some. In implementing the policy, users need to conform to those practices. It is also necessary to ensure all intents are consistent. Often, however, it is difficult to properly configure policy because a SCA composite structure can be complex, for example, it may have a recursive structure, intents have domain-specific constraints, etc.